$webwork.htmlEncode($page.space.name) : 0 Project Steering Committee
This page last changed on Dec 18, 2007 by groldan.
Welcome to the GeoServer organizational system, as with any open source project we start with people. SummaryThis document describes the role and responsibilities of the to be created Project Steering Committee, as well as the process under which it operates. Much of the definition and inspiration for the GeoServer PSC is taken from the MapServer Technical Steering Committee and the Plone foundation. The committee is made up of individuals based on merit irrespective of organization ties. StructureThe PSC is made up of individuals who are meant to represent the various communities which have a stake in GeoServer. An odd number is chosen to facilitate the voting process and help prevent ties. However, even with an odd number, the voting system may still allow for a tie in some cases. For this reason the PSC has an appointed Chair, whose sole responsibility is to break ties among the PSC. Turnover is allowed and expected to accommodate people only able to become active on the project in intervals. A PSC member may step down at any time. ProcessThe primary role of the PSC is to make decisions relating to project management. The following decision making process is used. It is based on the "Proposal-Vote" system.
When not to use the GSIPA GSIP is only needed for:
A GSIP is NOT needed for:
For minor decisions where feedback might be desired, the course of action to take is to consult the development list or raise it in an irc meeting. The GeoServer Project recognizes that it is run those who are actually doing the work, and thus we want to avoid high overhead for 'getting things done'. Snap Decisions For all decisions that are not official GSIP proposals, those 'present' (those in the IRC meeting or who bother to respond to an email within 4 days) are given the power to vote and decide an issue. The same voting procedures are used, but any vote that meets a -1 from any party present (even a new user), should go to a GSIP. ResponsibilitiesResponsibilities of PSC members fall into the following categories:
OperationsDay to day project management. Duties include: Weekly IRC Meeting AttendancePSC members are expected to attend one of the weekly IRC meetings. Of course this is not always possible due to various reasons. If known in advance that a member cannot attend a meeting the member should email the developer list. No reason need to be given for not attending the meeting. Meeting absences are subject to the following policies. If a member misses three consecutive meetings without prior notice, they are eligible to be voted off of the PSC. If a member continuously misses IRC meetings (with or without notice) they may be asked to step down to make way for a potentially more active member. Illness and vacation are acceptable exceptions to the above policies. However extended absence from the project may lead to the member being temporarily dismissed from the PSC. Mailing List ParticipationPSC members are expected to be active on both user and developer email lists, subject to open-source mailing list etiquette of course. It is a requirement that all PSC members maintain good public visibility with respect to activity and management of the project. This cannot happen without a good frequency of email on the mailing lists. PlanningLong term project management. Duties include: Guiding Major Development EffortsPSC members are expected to help guide the major development efforts of the project. This may include deciding which development efforts should receive priority when different efforts are in conflict. The PSC has the right to veto any proposed development efforts. A major development effort which is intended to become part of the core of GeoServer can be proposed by any interested part, PSC, or non PSC. However, the effort must be approved by the PSC before it can begin. Project PoliciesThe PSC is responsible for defining project policies and practiced. Examples include:
Current PSC
PSC Voting procedureBootstrappingFirst a chair is chosen by the current group of "active" committers. The Chair is then removed from the nominee list. Everyone on the email lists gets 5 votes for PSC,. Once the list is accepted by those nominated, a volunteer will privately gather the votes posting the results. The 7 nominees receiving the most 5 votes will be selected as the PSC. Future PSC members.A new PSC member can be nominated at any time. Voting for a new PSC is done by current active PSC members. There is no hard limit to the number of PSC members, but we want a relatively active PSC. PSC nominations are generally given in recognition to very significant contributions to the project. Membership is open to non-technical people, for example if someone is to make huge advances to the documentations or marketing of GeoServer, for example. Since we demand a fairly active PSC we expect turnover may be high compared to other projects, so initially we will aim to keep it around 7 PSC members. But given sufficient reason we will expand that. Nominated PSC members must recieve a majority of +1 vote's from the PSC, and no -1's. Stepping DownIf you find you cannot make meetings for a month or two, by all means step aside. Thank you so much for your time, if you want to groom a successor and then nominate them that is cool, but the nomination process still applies. If we do not hear from you for two months we will assume you lost, send out a search party and nominate your replacement. That is to say, status on PSC is lost if not active at all in a two month period of time. Of course you can come back on to the PSC if you become active again, but a new nomination procedure will be needed. Dissolution of PSCIf there are no suitable replacements, the PSC can decide to go down in number. If the number of active PSC members drops below 5, however, then TOPP reserves the right to take back active control of the project or to pass it on to an organization that will effectively steer it. We sincerely hope that will never happen, but want a policy in place so that we avoid a zombie project, forcing someone else to eventually fork GeoServer or some such. |
Document generated by Confluence on Jan 16, 2008 23:26 |